Backup Repository Structure
This page describes the logical backup structure used within the homelab, including how repositories and backup plans are organised in Backrest to support both local and offsite backups.
The backup system is designed around two primary repositories — one local and one remote — with mirrored backup plans for each. This structure provides fast local recovery while maintaining offsite redundancy for disaster recovery.
Repository Overview
Two Backrest repositories are currently configured:
1. backrest-local
backrest-local is the primary on-site backup repository.
- Location: Dedicated secondary hard drive
- Purpose: Fast local recovery
- Failure scenarios covered:
- Accidental deletion
- Data corruption
- Single disk failure
- Ransomware (with snapshot history)
This repository is optimised for performance and convenience, allowing rapid restores without relying on internet connectivity.
2. backrest-remote
backrest-remote is the off-site backup repository.
- Provider: Backblaze B2
- Protocol: S3-compatible API
- Purpose: Disaster recovery
- Failure scenarios covered:
- Hardware loss
- Fire / flood / theft
- Total server failure
- Site-wide incidents
This repository ensures that a complete copy of critical data exists outside the physical homelab environment.
Backup Plan Structure
Each repository has its own set of backup plans. Plans are intentionally mirrored between local and remote repositories to maintain consistency and ensure that all critical datasets exist in both locations.
Current Backup Plans
| Service / Dataset | Local Plan | Remote Plan |
|---|---|---|
| Immich | immich-local | immich-remote |
| Media Stack | mediastack-local | mediastack-remote |
| (Future services) | ... | ... |
Each plan targets the same data sources but writes to different repositories.
Immich Dataset Composition
| Component | Role / Purpose | Included in Backup |
|---|---|---|
| Immich database | Metadata and indexing | ✅ Yes |
| Uploads | Original photos and videos | ✅ Yes |
| Thumbnails | Generated previews | ✅ Yes |
| ML cache | Machine learning cache | ❌ No |
| Transcodes | Generated video transcodes | ❌ No |
Media Stack Dataset Composition
| Service | Role / Purpose | Included in Backup |
|---|---|---|
| Radarr | Movie management and acquisition | ✅ Yes |
| Sonarr | TV series management and acquisition | ✅ Yes |
| Overseerr | User request and approval system | ✅ Yes |
| Prowlarr | Indexer management | ✅ Yes |
| Bazarr | Subtitle management | ✅ Yes |
| Tautulli | Plex monitoring and analytics | ✅ Yes |
| Maintainerr | Media lifecycle automation | ✅ Yes |
| Plex (app) | Metadata, configs, watch state | ✅ Yes |
| Media files | Movies / TV / Music | ❌ No |
| Transcodes | Plex cache and transcode data | ❌ No |
Design Principles
1. Repository Separation
Local and remote backups are kept in completely independent repositories. This avoids shared failure modes and ensures that corruption or misconfiguration in one repository cannot affect the other.
2. Plan Mirroring
Every critical dataset has:
- One local plan
- One remote plan
This enforces symmetry and prevents scenarios where data exists in only one location.
3. Local First, Cloud Second
The system prioritises:
- Local restores for speed
- Remote restores for resilience
Most recoveries are expected to come from backrest-local, while backrest-remote exists for worst-case scenarios.
How This Supports the 3-2-1 Strategy
This structure directly implements the 3-2-1 backup rule:
-
3 copies of data
- Production data
- backrest-local
- backrest-remote
-
2 different storage systems
- Local physical disk
- Cloud object storage (Backblaze B2)
-
1 offsite copy
- backrest-remote in Backblaze B2
Scalability
This structure is designed to scale naturally as the homelab grows.
New services are added by simply creating two new plans:
<service>-local<service>-remote
This keeps the backup architecture consistent, predictable, and easy to reason about as additional workloads are introduced.